當一個需求完成開發，但還沒有要正式提供服務以前，你會怎麼辦呢？

這個情境其實相當常見，可能是期間限定的特殊活動、可能是只開放少數用戶測試的功能、也可能是公司沒有支撐該服務所需的經費。

這時候使用 feature flag 我認為會是比較好的做法，而這邊我推薦使用 GrowthBook 這個服務來進行。

這篇就來分享一下為什麼。

遲遲不 merge 進主幹？

我見過的其中一個做法，就是確定要上線以前，該功能的相關分支會持續處於未合併的狀態，各種測試就以分支為單位進行。

但這樣會有幾個主要的缺點：

遲遲未合併的分支是維護的負擔

在分支未合併的期間，主線的開發也不會就此停下，那麼開發分支與主線的差異就會越來越大，甚至可能讓測試失去意義，若需要持續透過 merge、 rebase 來更新分支，那三不五時出現的衝突 也會讓人容易與人發生衝突 也是一個維護的成本。

難以進行 A/B test 及封測

因為實際上主要分支就沒有這些功能的 code，如果真的要部署後進行 A/B test 及封測的話，可能就需要多準備不同的部署版本，要做 AB 分組的困難度也比較高。

使用 GrowthBook 來管理 feature flag

而 feature flag 就是一種功能開關的概念，一旦完成開發並經過測試的功能，就將其合併進入主線，但與此同時加上一個統一控制的開關，只有在滿足條件的情況下才將功能啟用。

而 GrowthBook 就是這樣的一個開源工具，他有提供 JS SDK 可以讓我們簡單的在專案中使用，概念就是透過一個統一的 設定檔 來進行管理，這個設定檔完全可以自行來部署、維護。

但其實他們提供的雲端管理服務相當的好用，我認為是可以考慮的方案。

feature flag 也需要維護

也許會有人顧慮這樣長久下來會有大量的開關充斥在程式之中，這的確是一個需要正視的問題，我曾經服務過的團隊中也有遇過這樣的情況。

大量的 feature flag 與各種組態設定混雜在一起，甚至有許多完全已經變成歷史本文的設定標籤，更讓設定檔難以使用及維護，但我認為這可以透過團隊的流程來解決。

可以安排在每次功能正式提供服務，不再需要 feature flag 的時候進行更新移除，也可以定一個固定的週期來移除久未更新的 feature flag，藉此來避免 feature flag 充斥於專案各處的情形。

而如果使用 GrowthBook 的雲端服務，可以像上圖那樣快速確認各個 feature flag 的使用、更新情形，我認為也是很有幫助的。